Modern enterprises typically use a lot of software systems in a system landscape. In most current system landscapes, many components are directly connected in a point-to-point connection. To facilitate communications, interfaces are developed between two systems so that a sender system can send a document to a receiver system via an interface. Those interfaces typically are hardwired into the application components and individual mappings programs. Because interfaces are required between any two systems, the growth of the number of computer systems results in a complicated network of connections. Under these conditions, managing the collaborative sharing of information is difficult. Therefore, companies face an increasing need for integration of and collaboration among their information and enterprise software systems.
Process integration has been implemented to provide a solution to this increasing need. Various systems, e.g. the “Business by Design's process agent framework PAF) are currently used for process integration. Process integration typically relies on central application servers to deal with the interplay between intra- and inter-component processes of different systems regarding modeling, transaction management, configuration, monitoring and extensibility. These central application servers, for example, (Enterprise Application Integration hubs) are connected to all systems in a system landscape, and route the exchanged messages between different systems and map the messages between the systems' formats. The communication with the central application servers is typically implemented in a message exchange framework based on SOAP/XML technology. The message exchange framework provides a platform that allows different interfaces to communicate using a uniform technology and promotes overall clarity and reduces maintenance effort. This central hub approach has several shortcomings. First, the hubs can only route a message based on the information contained in the message. Frequently, the messages don't contain enough information for correct routing decisions. Second, a source message can only be mapped into a target message format if it already contains all required information, which often is not the case as well. As a result, the sender system interfaces/messages often still have to be adapted for each receiver system
Furthermore, customers keep complaining about high total cost of ownership (TCO) and high total cost of development (TCD) in operations of a process integration product.
The main reason for the complaints is that the current application servers provided by software venders have severe limitations. For example, current application servers typically lack programming model and infrastructure for remote and peer-to-peer communication that provides uniform support for all communication channels, for managing the state of conversations with remote components, or for monitoring and error handling. Further, the existing infrastructure only provides disparate solutions for some of these capabilities for some channels and gaps are closed by patch solutions. According to state-of-the art application servers used for integrating a plurality of applications into one common process workflow, the data exchange between each of said applications while executing said workflow is hub-based. This means that the application server acts as a hub for receiving and processing calls from one of said plurality of applications or from an external application and for forwarding said call to a destination application. Setting up said application server and specifying allowed communication channels supported by said application server is a time consuming process and is an obstacle for the integration of a plurality of applications within one common, complex business process or workflow.
In a further disadvantageous aspect of state-of-the art systems for process integration, said systems have difficulties in supporting multiple different communication standards such as SOAP, remote procedure calls, and the like and are therefore of limited usage if a plurality of different applications using different communication standards need to be integrated in one common workflow. Said difficulties often arise because said systems typically are based on or favor one primary communication standard, typically a message-based one. Enterprise Service Buses (ESBs), for example, favor SOAP and Web Services. As a result, supporting other (not so commonly used) standards requires a translation from the primary message format into the other one. Thus, the transformation from or to said primary standard format often is a bottleneck in terms of performance and/or in terms of data format limitations. This may reduce performance and/or result in a loss of information during the format transformation. In addition, the code for process integration is not strictly separated from the business logic. As a consequence, the task of updating or modifying the integration logic or the overall business process workflow may require amendments to multiple, distributed code sections.
Moreover, the business and integration logic is often closely interwoven such that adapting to a new integration process often requires significant changes to the core business logic as well. This leads to a higher TCD for process integration in general and the absence of a unified approach across all applications results in a proliferation of tools and configuration environments, which increases TCO considerably and inhibits scenario-driven configuration. The typical solution to separate business and integration logic uses a framework driven control flow, in which application logic is implemented in business objects and the framework calls on the business objects to perform various functions. However, the drawback of a framework approach is that any logic that does not fit into the predefined framework logic either requires a modification to the framework itself or some “creative” code to lever the limitations of the framework. As the framework drives the application, it has to have a deep knowledge on how applications are built, which contradicts the separation of concerns if the framework and applications are developed by different organizations. This also complicates the enhancement of the framework if adoptions to unforeseen use cases must be supported by the framework. Further, the hidden control logic makes it harder for untrained developers, supporters or customers to understand the overall logic.
Therefore, there is a need for a system and method that provides a communication mechanism that separates business and integration logic and reduces the cost of adding new communication channels.